REMARKS 

Claims 1, 3 and 6-20 are now pending in the application. The Examiner is 
respectfully requested to reconsider and withdraw the rejections in view of the 
amendments and remarks contained herein. 

Rejection Under 35 U.S.C. § 102 

Claims 1, 3, 6-8, 10-13 and 15-20 stand rejected under 35 U.S.C. § 102(b) as 
being anticipated by Gleeson et al. (U.S. Pat. No. 5,959,989). This rejection is 
respectfully traversed. 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference." 
Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). See MPEP § 2131. 

Applicant submits that Gleeson fails to disclose each and every element required 
by claims 1 , 3, 6-8, 1 0-1 3 and 1 5-20. 

Applicant presents Figs. A and B below to facilitate the Examiner's understanding 
of the distinctions between the claims and Gleeson. Fig. A shows a flowchart illustrating 
the method for implementing multicast services according to claim 1, where the 
reference number steps 300, 310, 320, 330, and 340 are added based on Fig. 3 of 
Applicant's specification as originally filed. Fig. B shows a flowchart for distributing 
effectively multicast messages to subscribing entities of Gleeson. Applicant respectfully 
submits that Gleeson fails to anticipate at least steps 310, 320, and 330. These steps 
all appear in claim 1 . 
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Claim 1 is directed to a method for implementing multicast services. Claim 1 
requires that a network equipment, in response to a request packet sent by a multicast 
user who requests to loin in a multicast group , determines whether to permit a multicast 
user to loin in the requested multicast group using preset mapping relations . In other 
words, the preset mapping relations are used to determine whether to permit the 
multicast user to join in the requested multicast group. In addition, if a multicast user 
has a multicast authority, the mapping relation between the multicast user and the 
multicast authority is preset before the multicast user sends the request packet. 

Claim 1 recites: 

presetting a mapping relation between address information of 
multicast users and multicast authorities and a mapping relation between 
multicast authorities and multicast group addresses in a network 
equipment, at least one multicast user corresponding to different multicast 
authorities, at least one multicast authority corresponding to many 
multicast users; 

obtaining a request packet sent by a multicast user who requests to 
join in a multicast group; 

determining address information of the multicast user according to a 
Virtual Local Area Network identifier (VLAN ID) carried in the request 
packet and/or a frame number, slot number and port number of the 
network equipment to which the multicast user is connected (Step 31 0); 

determining whether the multicast user corresponds to a multicast 
authority according to the mapping relation between address information 
of multicast users and multicast authorities; 

determining whether the multicast group address carried in the 
request packet matches a multicast group address corresponding to the 
multicast authority of the multicast user among the mapping relation 
between multicast authorities and multicast group addresses (Step 330); 

if ves. permitting the multicast user to loin in the multicast group. 
othenft^ise. prohibiting the multicast user from joining in the multicast group 
(Step 340) 

Gleeson at best appears to show a mechanism for distributing multicast 
messages having group destination addresses to subscribing entities in a computer 
network. (See Abstract of Gleeson). Gleeson shows that NMD generates MVLAN ID 
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for each unique combination of VLANs (identified by VLAN designations), sucli tliat in 
response to receive a multicast message with the given group destination address; the 
MND attaches the generated MVLAN IDs to a copy of the message and distributes each 
copy to the subscribing entities. (See claim 1, col. 5, lines 51-67, and col. 10, lines 48- 

64 of Gleeson). 

Particularly, Each MND 226, 228 receives JoinGroup operation (IGMP request) 
sent by an entity wishing to receive a certain multicast message (step 300' of this 
Response), and in response to the JoinGroup operation (IGMP request), updates the 
table 308 stored in a portion of memory associating the VLAN designations of the 
subscribing entities with the group destination address (step 340' of Fig. B). (See col. 8, 
line 60-col. 9, line 10, col. 5, lines 55-67 of Gleeson). In response to a registration 
message, multicast controller 306 determines whether any MVLAN ID should be 
generated (step 340' of this Response). (See col. 10, lines 48-64 of Gleeson). 

Applicant respectfully asserts that Gleeson fails to anticipate each and every 
limitation of claim 1 . 

1 . Gleeson fails to disclose the claimed features of claim 1 . including at least 
steps 310. 320. 330 and 340 of Fig. A. 

Gleeson at best shows that in response to a JoinGroup operation (or IGMP 
request), the table 308 is updated or stored so as to associate VLAN destinations with a 
corresponding group destination address and determine whether to generate any 
MVLAN ID; in response to a LeaveGroup operation, the corresponding membership in 
table 308 is canceled. (See col. 8, line 60-col. 9, line 10 of Gleeson). 
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Thus, the information of the entity that sends the JoinGroup operation (or IGIVIP 
request) is not in table 308 before the entity successfully subscribes to the multicast 
messages by registering with the MND. Gleeson fails to teach determining whether to 
permit the entity to subscribe the multicast message and, thus, cannot teach or suggest 
those features recited in claim 1 . 

Further, Applicant notes that the Examiner in this Office Action compares the 
"MVLAN ID" to "multicast authority" and also compares the step 340' (col. 5, lines 59-61 
or col. 10, lines 48-53 of Gleeson) to the step 330 of claim 1 . Suppose the Examiner's 
comparison of the "IVIVLAN ID" to the "multicast authority" is correct, the step in col. 5, 
lines 59-61 or col. 10, lines 48-53 of Gleeson would be referred as to generate a 
multicast authority (MVLAN ID) for unique combination of VLANs that are matched to 
multicast group addresses." Thus, Applicant submits that the Examiner's comparison is 
not appropriate, because if a multicast has a multicast authority, the multicast user's 
multicast authority is preset in the network equipment. 

2. As stated in Section 1 of this Response, the usage of the mapping 
relations in the combination of steps 310. 320. 330 and 340 of claim 1 differs from those 
of table 308 and 312 of Gleeson. 

Fig. B of this Response illustrates that the tables 308 and 312 of Gleeson are 
used by MND to search for one or more MVLAN IDs according to multicast group 
address, so that the MVLAN IDs can be attached to a single copy of the multicast 
messages and distributes each copy to the subscribing entities. 

More specifically, upon receiving a multicast message to be sent to subscribing 
entities ( i.e. after permitting the entities to join in group address NEWSFROM27 ), 
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according to the information contained within table 308, MND finds that the VLANs 
associated with group address NEWSFROM27 include the red, blue and green VLAN 
designations, which corresponds to BLUE-GREEN MVLAN ID and RED-BLUE MVLAN 
ID according to table 312. Thus, MND attaches the BLUE-GREEN MVLAN ID and 
RED-BLUE MVLAN ID to two copy of the multicast message each and send each copy 
to subscribing entities. (See Fig. 3 and col. 8, line 60-col. 9, line 10 of Gleeson). 

Gleeson fails to teach that the table 308 and 312 are used to determine whether 
to permit an entity to register in a requested multicast group in response to a request 
sent by the entity. In contrast, the mapping relations of claim 1 are used as an access 
controlling policy before determining whether to permit a multicast user join in a 
requested multicast group. 

In view of the foregoing. Applicant submits that the usage of the mapping 
relations of claim 1 as illustrated in steps 310, 320 and 330 of Fig. A differ from those of 
the tables 308 and 312 in step 340' of Gleeson. 

3. The Examiner asserts that col. 13, lines 6-18 of Gleeson discloses the step 
340. Applicant respectfully traverses the Examiner's assertion. 

First, the process disclosed in col. 13, lines 6-18 of Gleeson occurs under the 
circumstances where intermediate devices 200-230 do not participate in the IGMP 
messaging and do not know which ports are coupled to the subscribers of a particular 
multicast stream. In those circumstances, devices 220-225 may simply fonward the 
multicast frame 420c to all ports 21 8, 21 8 which match the VLAN designation of the 
multicast message ( col. 12, line 66-col. 13, line 5 of Gleeson ). Particular, the multicast 
frame 420c are transmitted to entities through ports 21 8. 
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Second, Gleeson, in col. 13, lines 6-18, at best shows how to transmit a multicast 
frame 420c carrying a "red" VLAN designation to entities through ports coupled to a 
trunk. For example, upon receipt, intermediate device 221 determines that message 
402c carries a "red" VLAN designation and is intended for port numbers one and two 
through four, which are coupled to trunks 230, 231 and 232 and LAN 209, respectively. 
Nonetheless, intermediate device 221 is prevented from forwarding the message onto 
port numbers three and four due to the dissimilarity in VLAN designations between the 
message (i.e., red) and the corresponding ports (i.e., orange, blue and blue-green for 
port number three and blue and blue-green for port number four). In addition, the 
message was received on trunk 230. Accordingly, device 221 simply drives the 
message onto port number two coupled to trunk 231 , which is associated with the red 
VLAN designation (col. 13, lines 6-18). 

The above features of Gleeson merely show determining whether to permit some 
ports to forward a message carrving a certain VLAN designation after the entity 
subscribes to the message . 

In contrast, the features of claim 1 as illustrated in step 340 in require 
determining whether to permit the multicast user to loin in the multicast group according 
to the determination result of steps 310, 320. and 330 . Thus, the determination as 
shown in col. 13, lines 6-18 of Gleeson differs from that of step 340. 

As explained above, the features recited in claim 1, are not anticipated by 
Gleeson. Consequently, claim 1 is allowable over Gleeson, and claims 3, 6-8, 10 are 
allowable at least due to their dependence from allowable claim 1. Accordingly, 
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Applicant respectfully requests that the Examiner withdraw the rejection of claims 3, 6-8, 
1 0 under 35 U.S.C. § 1 02(b), and allow claims 1 , 3, 6-8, 1 0. 

Claim 1 1 recites features similar to the above distinguishing features of claim 1 . 
It is believed for at least similar reasons that Gleeson fails to teach or suggest the 
features recited in claim 11, claims 11-13, and 16: 

determining address information of the multicast user according to 
the request packet, the address information of the multicast user 
depending on location information of a connection between the multicast 
user and the network equipment; 

determining whether the multicast user corresponds to a multicast 
authority according to the mapping relations; 

determining whether the multicast group address carried in the 
request packet matches a multicast group address corresponding to the 
multicast authority of the multicast user according to the mapping 
relations; if the multicast group address carried in the request packet 
matches a multicast group address corresponding to the multicast 
authority of the multicast user, permitting the multicast user to use the 
requested multicast service; 

if the multicast group address carried in the request packet matches 
a multicast group address corresponding to the multicast authority of the 
multicast user, permitting the multicast user to use the requested multicast 
service; 

if the multicast group address carried in the request packet does not 
match a multicast group address corresponding to the multicast authority, 
prohibiting the multicast user from using the requested multicast service". 

Thus, Claims 11-13, and 16 are allowable. Claim 17 to is directed to a network 

equipment corresponding to the method claim 11. For at least similar reasons, claim 17 

and its dependent claims 1 8-20 also meet the requirements of patentability, and thus 

are allowable. 



Rejection Under 35 U.S.C. §103 

Claim 9 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Gleeson (U.S. Pat. No. 5,959,989) in view of Hayashi (U.S. Pub. No. 2003/0147392). 
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Claim 14 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Gleeson (U.S. Pat. No. 5,959,989) in view of Huang et al (U.S. Pat. No. 6,683,887). 
These rejections are respectfully traversed. 

Claim 9 depends from claim 1 and, thus, is allowable due to its dependency from 
claim 1 . 

Claim 14 depends from claim 13 and, thus, is allowable due to its dependency 
from claim 13. 

Conclusion 

It is believed that all of the stated grounds of rejection have been properly 
traversed, accommodated, or rendered moot. Applicants therefore respectfully request 
that the Examiner reconsider and withdraw all presently outstanding rejections. It is 
believed that a full and complete response has been made to the outstanding Office 
Action and the present application is in condition for allowance. Thus, prompt and 
favorable consideration of this amendment is respectfully requested. 
If the Examiner believes that personal communication will expedite prosecution of this 
application, the Examiner is invited to telephone the undersigned at (248) 641-1600. 

Respectfully submitted. 



Dated: December 28. 2009 By: /Joseph M. Lafata/ 

Joseph M. Lafata, Reg. No. 37,166 

Harness, Dickey & Pierce, P.L.C. 
P.O. Box 828 

Bloomfield Hills, Michigan 48303 

(248) 641-1600 

JML/PFD/tIp 
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